This chapter describes how to use the ATM interface. It includes the following sections:
LAN emulation provides support for virtual Token-Ring and Ethernet LANs over an ATM network. Refer to "How to Enter Addresses" for a discussion of ATM addressing.
Enter addresses in two ways, depending upon whether the address represents (1) an IP address, or (2) an ATM address, MAC address, or route descriptor, or MAC address, as follows:
Enter IP addresses in dotted decimal format, a 4-byte field represented by four decimal numbers (0 to 255) separated by periods (.).
Example of IP Address:
01.255.01.00
Enter ATM addresses, MAC addresses, and route descriptors as strings of hexadecimal characters with or without optional separator characters between bytes. Valid separator characters are dashes (-), periods (.), or colons (:).
Examples of ATM address, MAC address or route descriptor
A1FF01020304 or A1-FF-01-02-03-04 or A1.FF.01.02.03.04 or 39.84.0F.00.00.00.00.00.00.00.00.00.03.10.00.5A.00.DE.AD.08 or A1:FF:01:02:03:04 or even A1-FF.01:0203:04
Each type of address requires a different number of hexadecimal characters:
This information applies to addresses entered for ATM, LAN emulation, Classical IP and ARP over ATM, IPX over ATM, and ARP over ATM.
Protocols that run natively over an ATM interface can use ATM-LLC multiplexing to share ATM addresses and both SVC and PVC channels between users. ATM-LLC is implicitly configured when the protocols are configured and can be monitored using the ATM Config+ command prompt from t 5. There are no explicit configuration options for the ATM-LLC multiplexing function. For example, if two protocols which use ATM-LLC multiplexing are configured to use the same local ATM address (local endpoint), this implicitly configures ATM-LLC to use the same shared ATM address for both protocols.
See "ATM-LLC Monitoring Commands" for additional information.
Sharing of ATM addresses or SVC/PVC channels is not possible between protocols that use the ATM-LLC multiplexing function and those that do not use the ATM-LLC multiplexing function (such as Classical IP). Currently, Server Cache Synchronization Protocol (SCSP) and APPN are the only two protocols that use the ATM-LLC multiplexing function.
An ATM Virtual Interface (AVI) creates the appearance of multiple ATM interfaces when, in fact, there is only one physical ATM interface. One or more AVIs can be configured for each physical ATM interface on the device. AVIs have the following characteristics:
For example, one can configure IP on interface 0 (which is a real ATM interface) with IP address 9.1.1.1 and another instance of IP with address 9.2.1.1 on interface 1 (which is an AVI). Whether an interface is a real ATM interface or a virtual interface configured on a real interface makes no difference to the protocol (IP in the example). In addition, whether virtual interface 1 is configured on top of real ATM interface 0 or some other physical ATM interface is also transparent to the protocols.
Major advantages of using the ATM Virtual Interfaces are:
The actual number of AVIs that can be configured on an ARI is limited by physical resources, such as memory, available on the device. The total number of interfaces that can be created depends on the data packet size for the interfaces and is limited to a maximum number of 253 per device.
The use of AVIs significantly improves the configuration options for protocols such as IPX that are limited to one instance or address per ATM interface. By configuring an appropriate number of AVIs, several IPX addresses can be supported on each physical ATM interface.
In order for multicast to operate correctly, each logical subnet must be configured on a different interface because multicast routing protocols typically function in such a way that a packet coming in from a device interface will never be sent out over the same interface. Thus, if more than one subnet is configured on an interface and a source in one subnet sends a multicast packet to a member in another subnet defined on the same interface, this member will never receive the packet.
By creating an individual virtual interface for each subnet, packet multicasting can be performed successfully. Typically, the number of ATM interfaces on a device will be limited, in turn limiting the number of subnets that can be correctly configured for multicast operation. However, by creating as many AVIs as needed (according to the number of subnets that are required to be configured on the device), the number of physical ATM interfaces will no longer limit the number of subnets that can be configured on a device for correct multicast operation.
For example, the "one-armed" router cannot support multicast traffic over interfaces other than ELANs without the AVI feature, because incoming packets will never be sent out the same interface and will be discarded instead.
For example, when multiple subnets are configured on a single physical ATM interface, the interface will have to reduce the maximum transmission unit or MTU (the maximum packet size that can be sent or received over that interface) to the smallest MTU of all subnets sharing the same interface. However, if multiple AVIs are created on that ARI and each IP subnet is configured on a different AVI, every subnet can continue to use its existing MTU size without consideration of other subnets configured on the same physical ATM interface. This avoids possible reduction in throughput and delays due to packet fragmentation and reassembly caused by MTU size reduction.
Another performance improvement can be achieved by distributing the number of protocol addresses configured on a physical interface over different virtual interfaces configured on the same physical interface. The per-interface protocol lists get shortened, resulting in faster searches and reduced processing time.
The disadvantages of using ATM Virtual Interfaces are:
In the current implementation, resource allocation is on demand. Each physical ATM interface has a pool of resources that are available for use by all AVIs and the single ARI itself.
| Note: | Because all resources are shared among the ARI and all its AVIs, an ESI added
on an ARI is automatically available to all AVIs configured on the ARI.
You should not assign the same ESI and selector combination to two different
protocol clients using the same ARI even though they are configured on
different AVIs.
Limited PVC sharing is allowed across the ARI and the AVIs configured on the ARI. PVC sharing is limited to different protocol instances. Multiple instances of the same protocol are not allowed to share the same PVC. |